Facebook的实时Hadoop系统

http://blog.solrex.org/articles/facebook-realtime-hadoop-system.html

作者：杨文博

Facebook 在今年六月 SIGMOD 2011 上发表了一篇名为“Apache Hadoop Goes Realtime at Facebook”的会议论文 (pdf)，介绍了 Facebook 为了打造一个实时的 HBase 系统使用到的独门秘技。由于该论文提到的应用场景与小弟负责的系统要解决的问题域有相似之处，因而抽时间仔细阅读了这篇论文。下面便是结合论文的内容，谈一谈我的一些看法和感想，如有谬误，敬请指正。

这篇 10 页的长文主要的内容是 Facebook 在 Hadoop 系统上的工程实践，这些工程实践的目标则是题目所点出的——实时。虽然缺乏 Hadoop 系统的开发或使用经验，但是我觉得并没有妨碍我对这篇论文的理解。在我的脑子里，HDFS 就是 GFS，HBase 就是 BigTable。它们实现上可能有差异之处，但主要的思想应该是相通的。如果熟悉 GFS 和 BigTable 那两篇文章，这篇文章就可以视为 GFS 和 BigTable “进阶”。

1. 应用场景和需求

文章的最初是一些背景介绍，主要给出了三类应用场景：Facebook Messaging、Facebook Insight 和 Facebook Metrics System(ODS)。Messaging 就是 Facebook 的新型消息服务，Insight 是提供给开发者和网站主的数据分析工具，ODS 则是 Facebook 内部的软硬件状态统计系统。这三个应用场景都有各自的特色，但简单地来说，面临的问题是同样的：单机或者拆分的关系型数据库无法满足需求。

基于应用场景的数据特征，Facebook 抽象出了几个对存储系统的需求。由于描述起来有些复杂，例如 Efficient and low-latency strong consistency semantics within a data center，这些需求就不一一列举了。相比需求，更让人感兴趣的是它的那些“非需求”，总共有三条：

1. 容忍单数据中心内部的网络分化，Facebook 认为这个问题应该从网络硬件层面（做冗余设计）而不是软件层面去解决；
2. 单个数据中心宕机不影响服务，Facebook 认为这种灾难很难发生，因而愿意接受这种风险；
3. 跨数据中心的数据热备服务能力，Facebook 假设用户数据是分配到固定的数据中心的，可能带来的响应延迟问题应该通过缓存来解决。

从这些“非需求”上可以看出，Facebook 考虑的是更实际的情况，而不是一个理想中的分布式系统，在这点上有一定的借鉴意义。

根据以上的需求和非需求，Facebook 自然而然地给出选择 Apache Hadoop 这套系统的理由，其中有社区的成熟度、Hadoop 在一致性、扩展性、可用性、故障容忍、读写效率等等的各项优点，这些方面的优点也是有目共睹的。

2. 打造实时的 HDFS

HDFS 本身设计来支持离线 MapReduce 计算的分布式文件系统，虽然在扩展性和吞吐上有很好的表现，但在实时性方面表现并不好。如果想让基于 HDFS 的 HBase 有更好的性能，HDFS 层的优化是不可避免的。为了把 HDFS 打造成一个通用的低时延文件系统，Facebook 主要做了以下一些优化。

2.1 实现 NameNode 的高可用——AvatarNode

HDFS 的 NameNode 是系统单点，就意味着 NameNode 挂掉会导致系统的不可用。NameNode 重启时加载内存快照、应用log和收集 DataNode 的数据块信息报告大概需要 45 分钟。即便使用了 BackupNode，仍然需要收集数据块信息报告，切换的时间仍然可能大于 20 分钟。但有实时性需求的系统一般都会要求系统 24x7 的可用性，因而 Facebook 对单点的 NameNode 进行了改进，实现了 NameNode 的双节点热备，称为 AvatarNode，如下图所示：

 

AvatarNode